REMARKS 



Claims 1-3, 6-23, 25-34, 36-45,47-55, 58 and 60-69 are pending in the 
application. 

Claims 1-3, 6-23, 25-34, 36-45,47-55, 58 and 60-69 have been rejected. 

Claims 1,16, 17, 19, 20, 21, 22, 23, 33, 34, 44, 45, 55 and 68 have been amended. 

Claims 2 and 3 have been cancelled. 

35 U.S.C. S 103(a) Rejection, Pell in view of Fisher 

Claims 1-3, 6, 8-13, 16, 19-23, 25-30, 33-34, 36-41, 44-45, 47-52, 55, 58, and 60- 
65 stand rejected under 35 U.S.C. § 103(a) as purportedly being unpatentable over U.S. 
Patent No. 7,392,540 issued to Pell. ("Pell"), in view of U.S. Patent No. 6,212,51 1 issued 
to Fisher, et al. ("Fisher"). Applicants respectfully traverse this rejection. 

Claim 1 

Applicants respectfully submit that the Office Action does not establish a prima 
facie case of obviousness in rejecting these claims, as amended. In order to establish a 
prima facie case of obviousness, all claimed limitations must be taught or suggested in 
the prior art. 

Pell discloses a method of enabling secure communications between a customer 
computer system and a vendor support representative computer system by utilizing a 
collaboration service center that includes a "rendezvous service" and an "interaaction 
service" (col 2, lines 50-54). The rendezvous service receives requests for collaboration 
and matches such requests in accordance with predefined rendezvous rules (col 2, lines 
61-64). Once the desired match has been made, then further interaction between a 
customer and a support representative is managed through the interaction service (col 3, 
lines 2-6). 
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The Office Action cites several passages of Pell as prior art describing the wait 
request in claim 1, including the following (col 5, lines 40-52): 

A support or administrative user becomes known to rendezvous service 102 by 
issuing a request via path 154 to identify the agent as available for processing of 
support requests. Such a support or administrative user essentially "logs in" to the 
rendezvous service through such a request via path 154. 

Having so identified an appropriate agent, rendezvous service 102 initiates via 
path 160 interaction service 104 to permit further interaction between the selected 
agent and the requesting customer or user. Specifically, interaction service 104 
exchanges requests and responses with support proxy 106 and with the agent 
browser 110 via paths 156 and 158, respectively. 

From the above, the Office Action seems to indicate the request via path 154 is 
the wait request. From Figure 1 this request is sent via the agent browser 1 10 to 
collarboration server 100. While this appears similar to page 15, line 23-29, where the 
agent logs in and establishes an HTTP connection, Applicants submit that the procedure 
of logging into the rendezvous service as described above is not comparable to enabling a 
web server to push an asynchronous message to a web browser, wherein the web browser 
waits for the asynchronous message and is capable of concurrently performing other 
tasks, as claimed in claim 1 (this is supported by the Specification p. 2, lines 28-31; p. 5, 
lines 4-6; p. 6, lines 4-6, p. 17, lines 5-8), where the web browser will not be blocked 
from performing other tasks while the web browser waits for a response from an HTTP 
request. 

The procedure described in Pell of logging into the rendezvous service is also not 
comparable to causing a web browser to provide a wait request as claimed in claim 1 . As 
supported by the Specification in Figure 5, a wait request may correspond to a URL that 
contains certain information that may be needed for an asynchronous message to be 
pushed to java applet 116 (Specification, p. 17, lines 14-18). Furthermore, the wait 
request URL specifies a target process, for instance a communications client service 160, 
from which an asynchronous message would be received. 

Applicants agree with the Examiner that Pell does not teach a wait request that 
specifies a target process (OA, p. 3), but respectufully disagree that Fisher teaches this 
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element. Fisher relates to the management of computer networks using management 
objects and resource control variables. In particular, Fisher discloses a method of 
restricting access to management objects and event notifications generated by 
management objects (col. 4, lines 40-48). As disclosed in Fisher, the method for 
controlling access to management objects involves the use of an access control database, 
which defines access rights through the use of access control objects. Access control 
objects include group objects and rule objects (col. 3, lines 10-20). 

The Office Action cites several passages of Fisher as prior art describing a wait 
request that specifies a target process, as described in claim 1, including the following 
(col 4, lines 43-48): 

Furthermore, for purposes of this document, we are primarily concerned with 
methods of restricting access to management objects and to event notifications 
generated by management objects, and thus we are not particularly concerned 
with the content and functions of the management objects" (col 4, lines 43-48). 

Applicants respectfully submit that neither the paragraph above, which seems to 
describe the scope of the document, nor any other passage cited in Fisher discloses a wait 
request, let alone a wait request that specifies a target process of a plurality of processes, 
as claimed in claim 1 . 

The other passages cited by the Office Action in Fisher concern limiting access to 
event notifications, and are unrelated to the elements recited in claim 1 . For instance, 
Fisher describes limiting access to event notifications in the following terms: 

In the present invention, access to Events (Notifications) is controlled in the same 
way as access to objects, using rules in the access control rule base. [. . .] An 
example of the event notification access control problem is as follows: a 
telephone network provider does not want customer A to receive notifications 
about new network resources installed for customer B, but customer A registers 
itself to receive all event notifications. The present invention solves the event 
notification access control problem by (A) adding event notifications to the set of 
operation types that are governed by rules in the access rules database, and (B) 
adding a filtering mechanism to the system's event router that filters event 
notification messages based on the rules in the access rules database, (col 13, line 
56-col 14, line 4) 
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The process of controlling/limiting access to event notifications described above 
is not comparable to the method of communicating, including causing a web server to 
push an asynchronous message to a web browser, as recited in Claim 1 . In particular, the 
communications method claimed in claim 1 does not include a set of access control rules 
in an access rules database, or a filtering mechanism that filters event notification 
messages based on such rules, as described in the passage in Fisher quoted above. 

To further clarify the differences between Pell and Fisher, on the one hand, and 
claim 1 on the other, claim 1 has been revised to recite controlling a user interface 
presented by a web browser comprising causing a web server to push an asynchronous 
message to the web browser in response to an incoming event, wherein: 

the web browser waits for the asynchronous message and is 
capable of concurrently performing other tasks; 

Neither Pell, which pertains to a rendezvous service and an interaction service to 
facilitate communication in accordance with specified rules, nor Fisher, which pertains to 
a method for controlling access to management objects, individually or in combination, 
discloses all of the elements of the method for communiating disclosed in claim 1 . In 
particular, neither reference discloses a web browser that waits for an asynchronous 
message while concurrently being capable of performing other tasks, causing a web 
server to push an asynchronous message, or causing a web browser to provide a wait 
request, in each case as claimed in claim 1. Even if Pell and Fisher were combined as 
suggested by the Office Action (even though there appears to be no motivation or 
suggestion for the combination), the resultant combination would still not result in a 
method for communicating which includes causing a web server to push an asynchornous 
message to a web browser, a web browser that waits for an asynchronous message while 
concurrently being capable of performing other tasks, as recited in claim 1. 

The above remarks made with respect to independent claim 1 apply with equal 
force to independent claims 16, 19-23, 33-34, 44-45, and 55, which have been amended 
to include substantially similar features. For at least the foregoing reasons, Applicants 
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respectfully request the Examiner's reconsideration and withdrawal of the rejections to 
these claims, as well as all claims depending thereon, and an indication of the 
allowability of the same. 

35 U.S.C. $ 103(a) Rejection. Pell and Fisher in view of Gupta 

Claims 7, 14-15, 18, 31-32, 42-43, 53-54, and 66-68 stand rejected under 35 
U.S.C. § 103(a) as purportedly being unpatentable over Pell and Fisher, in view of U.S. 
Patent No. 6,763,384 issued to Gupta, et al. ("Gupta"). Applicants respectfully traverse 
this rejection. 

As disclosed in the Specification, "[w]hat is needed is a secure and scalable way 

to allow a web server to asynchronously push a message to a web browser. It is desirable 

that the web browser not be blocked in order to receive information from the web server 

so that the web browser can perform other tasks" (page 6, lines 3-5). Gupta seems to 

teach away from this, as can be seen from the following excerpt: 

A third method for notification is based on a "push" by the server, on a persistent 
connection initiated by the client. Once the client application has connected to the 
server, it remains connected. When the server has some information to send, it 
pushes that information on this open connection. [. . .] the method wastes server 
resources. The server needs to have open connections with a large number of 
clients that wish to receive real-time notification. This puts a restriction on the 
number of clients that can be on-line simultaneously and makes the system less 
scalable. To make an open connection, some form of "I am alive" message has to 
be periodiclly exchanged between the server and the client, and this too leads to 
bandwidth wastage, (col. 2, lines 10-26) 

In addition to teaching away from the "push" notification method, Gupta neither 
teaches nor discloses causing a web browser to provide a wait request to a web server, as 
recited in claim 7 (which is ultimately dependent on claim 1). Therefore, even if Pell, 
Fisher and Gupta were combined as suggested by the Office Action (even though there 
appears to be no motivation or suggestion for the combination), the resultant combination 
would still not result in a method for communicating which includes causing a web server 
to push an asynchornous message to a web browser, and a web browser that waits for an 
asynchronous message while concurrently being capable of performing other tasks, as 
recited in claim 1 (on which claim 7 ultimately depends), or a web browser that is not 
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blocked from receiving information from a web server while waiting for an asynchronous 
message, as recited in claim 16 (on which claim 18 depends). 

The above remarks are made with respect to claims 7, 14-15, 18, 31-32, 42-43, 
53-54, and 66-68, as amended. For at least the foregoing reasons, Applicants respectfully 
request the Examiner's reconsideration and withdrawal of the rejections to these claims, 
as well as all claims depending thereon, and an indication of the allowability of the same. 

35 U.S.C. S 103(a) Rejection. Pell and Fisher in view of Wick 

Claim 17 stands rejected under 35 U.S.C. § 103(a) as purportedly being 
unpatentable over Pell and Fisher, in view of U.S. Patent No. 6,691,162 issued to Wick 
("Wick"). Applicants respectfully traverse this rejection. 

It is respectfully submitted that for the same reasons that claim 16 should be 
allowable, claim 17 (which is a dependent claim on claim 16) should also be allowable. 

35 U.S.C. S 103(a) Rejection, Pell and Fisher in view of Abbott 

Claim 69 stands rejected under 35 U.S.C. § 103(a) as purportedly being 

unpatentable over Pell and Fisher, in view of U.S. Patent No. 7,089,497 issued to Abbott, 

et al. ("Abbott"). Applicants respectfully traverse this rejection. 

It is respectfully submitted that for the same reasons that claim 1 should be 

allowable, claim 69 (which is a dependent claim on claim 1) should also be allowable. 
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CONCLUSION 



In view of the amendments and remarks set forth herein, the application and the 
claims therein are believed to be in condition for allowance without any further 
examination and a notice to that effect is solicited. Nonetheless, should any issues 
remain that might be subject to resolution through a telephonic interview, the Examiner is 
invited to telephone the undersigned at 617-725-8953. 

If any extensions of time under 37 C.F.R. § 1.136(a) are required in order for this 
submission to be considered timely, Applicants hereby petition for such extensions. 
Applicants also hereby authorize that any fees due for such extensions or any other fee 
associated with this submission, as specified in 37 C.F.R. § 1.16 or § 1.17, be charged to 
deposit account 502306. 

If the Examiner believes a telephone conference would expedite prosecution of 
this application, please telephone the undersigned at 617-725-8953. 



Respectfully submitted, 




Nicholas L. Baggale^ 
Reg. No. 54,973 
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